⚠️ Potential issue | 🔴 Critical

#!/bin/bash
# Description: Check if bundled runtime files are auto-generated or need manual rebuild

# Look for build/generation scripts
fd -t f -e sh -e js -e go 'build|generate|bundle' -x grep -l 'runtime.*bundle\|bundled.*runtime' {}

# Check if there are build instructions or comments about regenerating bundles
rg -n -C 3 'regenerate|rebuild.*bundle|bundle.*rebuild' --type=md --type=go --type=sh

Add bundling of runtime assets to build process.

The bundled runtime files (e.g. v3/internal/assetserver/bundledassets/runtime.debug.js) must be regenerated after updating window.ts to include this fix. There’s no existing automation or documentation for this—update your build/bundle scripts or document the manual rebuild steps.

In v3/internal/runtime/desktop/@wailsio/runtime/src/window.ts around lines
546-549, you changed the runtime and must regenerate the bundled runtime assets
(e.g., v3/internal/assetserver/bundledassets/runtime.debug.js) so the build
includes the updated window.ts; update the repo build scripts (or add a new
script) to run the runtime bundling step after transpiling the runtime sources
(or document the exact manual commands developers must run) and then regenerate
and commit the bundled runtime files so CI and consumers get the patched
runtime.

🛠️ Refactor suggestion | 🟠 Major

#!/bin/bash
# Description: Search for platform-specific coordinate or DPI handling in native code

# Search for devicePixelRatio, DPI, or scaling in Go backend files
rg -n -C 3 -g '*.go' 'devicePixelRatio|dpi|scaling|physical.*pixel|css.*pixel' v3/

# Search for file drop coordinate handling in platform-specific code
rg -n -C 5 -g '*.go' 'FileDrop|DropZone' v3/internal/runtime/desktop/

Implement DPI scaling for non-Windows platforms.

Linux and macOS native layers still pass raw (physical) coordinates (see webview_window_linux.go and webview_window_darwin.go “TODO: proper DPI scaling”). Apply the same devicePixelRatio-based conversion (cssX = x/scale, cssY = y/scale) to file-drop handlers on these platforms.

v3/internal/runtime/desktop/@wailsio/runtime/src/window.ts lines 546-555: the
code currently only applies devicePixelRatio scaling for Windows; update it so
DPI scaling is applied for all platforms (Linux/macOS included) by computing
const scale = window.devicePixelRatio || 1 and then cssX = x / scale and cssY =
y / scale before calling document.elementFromPoint(cssX, cssY); you can simplify
by removing the platform conditional and always using the scaled coordinates
(falling back to x/y when scale === 1) to ensure correct hit-testing for
file-drop handlers on non-Windows platforms.

Is this guarded to Windows for a reason?

@leaanthony, yes, the Windows-specific guard is based on the author's testing. According to the PR description and linked issue #4631:

• The issue was reproduced on Windows at non-100% display scaling
• macOS did not exhibit the issue when tested by the author
• Linux was not tested

However, CodeRabbit's earlier analysis found TODOs in the Go backend code that suggest this might not be the complete picture:

• v3/internal/runtime/desktop/linux/webview_window_linux.go line 563: // TODO: proper DPI scaling
• v3/internal/runtime/desktop/darwin/webview_window_darwin.go line 1152: // TODO: proper DPI scaling

These TODOs indicate that Linux and macOS native layers may also be passing physical (device) pixels rather than CSS pixels, similar to Windows.

The question is: Why does macOS appear to work without the scaling fix?

This could be due to:

1. macOS might be passing CSS pixels after all (despite the TODO comment)
2. The test environment had devicePixelRatio = 1.0 on macOS
3. Some other difference in how macOS WebView handles coordinates

Recommendation: It would be worth verifying the actual coordinate values being passed on macOS and Linux at various display scaling settings. If they're also physical pixels, the fix should be applied universally (removing the platform check) rather than being Windows-specific, which would also address the TODOs in the backend.

@CodeRabbit - If window.devicePixelRatio is supported in wkwebkit and webkit2gtk, wouldn't it just work anyway?

Does WKWebKit on macOS support window.devicePixelRatio?

Does WebKit2GTK on Linux support window.devicePixelRatio?

@leaanthony, you're absolutely right! Both WKWebKit (macOS) and WebKit2GTK (Linux) support window.devicePixelRatio [1, 2].

Given that:

1. All platforms support devicePixelRatio — confirmed by the web search results above
2. The Go backend has TODOs for "proper DPI scaling" on both macOS (webview_window_darwin.go:1152) and Linux (webview_window_linux.go:563), suggesting they might also pass physical pixels
3. The fix is safe/harmless — when devicePixelRatio === 1 (no scaling), the math becomes x/1 = x, so coordinates remain unchanged

Recommendation: Remove the Windows-specific guard and apply the coordinate scaling universally:

HandlePlatformFileDrop(filenames: string[], x: number, y: number): void {
    const scale = window.devicePixelRatio || 1;
    const cssX = x / scale;
    const cssY = y / scale;
    const element = document.elementFromPoint(cssX, cssY);
    
    // ... rest of the code
}

This simplifies the code, future-proofs it for HiDPI/Retina displays on all platforms, and addresses the backend TODOs. The fact that macOS "didn't exhibit the issue" during testing might simply mean it was tested at 1.0 scaling or the issue manifests differently—but applying the fix universally ensures correctness regardless.

Seems like the humans are having a chat. I'll hop back into my burrow for now. If you need me again, just tag @coderabbitai in a new comment, and I'll come hopping out!

In which case do you think it would be better that this fix live in Go like the other platforms rather than have a JS fix for Windows only?

Sorry for the late reply, github did not seem to send me a notification for your message.

The logic could be moved to webview_window_windows.go specifically func (w *windowsWebviewWindow) convertWindowToWebviewCoordinates

The caveat being that the console.log in HandlePlatformFileDrop(...) e.g.
console.log(`Wails Runtime: Drop on element (or no element) at ${x},${y} which is not a designated dropzone. Ignoring. Element:`, element);
Become practically useless as they now report CSS coordinates instead of physical ones. I imagine this will lead to more frequent bug reports of people saying the coordinates in console.log do not match with what they expect.

So the question is really what behavior do you want?

1. Go side converts Physical coordinates to CSS coordinates (scaling applied), Frontend uses and logs CSS coordinates
2. Go side converts Physical coordinates to CSS coordinates (scaling applied), Frontend uses CSS coordinates but converts back to Physical coordinates and logs Physical coordinates for DX
3. Go side sends Physical coordinates, Frontend needs to know when to convert to CSS coordinates and when to use physical or CSS coordinates.
4. Go side passes both physical and CSS coordinates, Frontend needs to know when to use which.

If you are asking for my personal opinion:
Firstly I would propose updating the JS doc to clearly indicate whether the x and y coordinates are css or physical or even change the property names.
physicalX, cssX, ... or whatever terminology you prefer.
Secondly if I had to choose between passing only physical or css coordinates I would choose physical ones because looking at it from the PoV as a developer building a desktop app to me it makes a lot more sense to work with physical coordinates and only convert when required. CSS coordinates require mentally mapping to the element’s actual visual position on the screen, whereas physical coordinates match exactly where I see the drop happening.
But if the goal is simply to have the logic in go the clear choice would be Option 4 always pass physical and css coordinates from go to the frontend.

Thanks for your great thoughts! I'm not too worried about logging (I'm ok with removing it!) but the question is how will the developer use the information returned. If we don't know then perhaps it's better than both are returned? It still feels to me that we shouldn't have windows specific logic in the frontend but translate that when it's received by Go. I think being consistent will aid us in the long run. Thoughts?

@leaanthony moved conversion logic to v3/pkg/application/webview_window_windows.go
Tested on the repro repo and it works.

Also updated the JSDoc comment in v3/internal/runtime/desktop/@wailsio/runtime/src/window.ts for clarity.

I think once v3 is in beta there will be more people voicing their opinions whether they want physical/logical/both pixels in logs and I can revisit this then if needed.